Repository-Independent System and Method for Asset Management and Reconciliation

ABSTRACT

A system and method for managing network device configurations is described. In one embodiment a device configuration is represented by configuration knowledge and configuration data, wherein the configuration knowledge may comprise one or more configuration knowledge instances, and the configuration data may comprise one or more configuration data instances. In preferred forms, the configuration knowledge instances and configuration data instances may comprise one or more schemata, which may be created, modified, or deleted without affecting other portions of a configuration knowledge instance or configuration data instance.

PRIORITY

This application is a divisional application of U.S. application Ser.No. 10/617,420, filed Jul. 10, 2003, entitled Repository-IndependentSystem and Method for Asset Management and Reconciliation, which claimsthe benefit of U.S. provisional patent Application No. 60/395,698, filedJul. 11, 2002, entitled Repository-Independent System and Method forAsset Management and Reconciliation, which are both incorporated hereinby reference in their entirety.

FIELD OF THE INVENTION

The present invention relates to network device management. Inparticular, but not by way of limitation, the present invention relatesto systems and methods for maintaining network device configurationsand/or generating network device configurations.

BACKGROUND OF THE INVENTION

Network devices such as routers, switches and optical devices arebecoming increasingly more complicated. Typical network devices nowrequire thousands of lines of specialized configuration instructions tooperate properly. Unlike most software applications, the instructionsthat operate network devices can be changed on a frequent basis, and thenature of network devices often requires that each version of a device'sconfiguration be stored. Because changes are so frequent, sizablerepositories of old configurations are generated for each device. Whenthese sizable repositories are accumulated across the thousands ofnetwork devices that frequently make up a network, cumbersome,inefficient repositories are created. In some cases, these repositoriesare so large that they are not useful.

Present network architecture generally requires that configurationinstructions and the capabilities of a network device (referred to as“configuration knowledge”) be stored together as an atomic unit. Thissingle-data-model approach has proven difficult to maintain forsophisticated networks. When network administrators, for example,archive only the configuration data—the actual configurationinstructions or some indication thereof—the configuration knowledge thatwas used to generate those configuration instructions is lost. When thenetwork administrators attempt to archive both the configurationinstructions and the configuration knowledge for each configurationchange, the size of the archived file becomes too large because theknowledge used to generate the configuration is many times the size ofthe actual configuration.

For a given version of a network device, the configuration knowledge isgenerally invariant, e.g., the operating system and hardware for thenetwork device do not change. Thus, repeatedly archiving theconfiguration knowledge is wasteful.

Network administrators have also found that the single-data-modelimplementation makes reverting to previous configurations difficult.When the configuration data and the configuration knowledge are bundledtogether as an atomic unit, network administrators have significantdifficulty in reverting to a previous device configuration when both theconfiguration instructions and the configuration knowledge change. Forexample, when a network device is upgraded to run a new version of itsoperating system, both the configuration knowledge and the configurationdata are changed. If the upgrade fails, rolling back the changes to aknown state for the previous operating system.

Present network technology suffers from yet another drawback in that itlacks a common information model that can be used to derive each of theapplication-specific configurations. This lack results in networkapplications having difficulty in retrieving and sharing networkinformation from different network devices. Even more problematic is thefact that the lack of the common information model results in networkapplications sharing network data infrequently. For example, eachapplication might implement its own procedure for discovery of networkdevices because it cannot understand information generated by anothernetwork application.

SUMMARY OF THE INVENTION

Exemplary embodiments of the present invention that are shown in thedrawings are summarized below. These and other embodiments are morefully described in the Detailed Description section. It is to beunderstood, however, that there is no intention to limit the inventionto the forms described in this Summary of the Invention or in theDetailed Description. One skilled in the art can recognize that thereare numerous modifications, equivalents and alternative constructionsthat fall within the spirit and scope of the invention as expressed inthe claims.

In one embodiment of the present invention, the configuration of anetwork device—also referred to as network resources—is separated intotwo portions: configuration knowledge and configuration data.Configuration knowledge for a particular network device is referred toas a configuration knowledge instance. Similarly, configuration data fora particular network device is referred to as a configuration datainstance.

Configuration knowledge abstractly represents the capabilities of anetwork device, but not necessarily the actual configuration of thatdevice. For example, the configuration knowledge for a router mightindicate the types of traffic conditioning, chip organization, androuting protocols that are available to that router. Configurationknowledge can be comprised of individual configuration schemata, whichdefine the individual portions that make up the complete configurationknowledge.

Because configuration knowledge for a device can be constructed from aset of individual schemata, when the capabilities of that network deviceare changed, the relevant portion of the configuration knowledgeinstance can be changed without otherwise rebuilding the entireconfiguration knowledge instance. For example, if a new card is added toa router, then the schemata for that new card is added to theconfiguration knowledge instance. The remaining portion of theconfiguration knowledge instance, however, may remain unchanged.

The configuration data for a particular network device can be derivedfrom the configuration knowledge instance for that device. Moreover,each configuration data instance can be associated with a particularversion of the configuration knowledge instance. For example, if arouter is updated with a new operating system (OS), a new version of theconfiguration knowledge instance that reflects the new OS is created.Subsequent sets of configuration data can be associated with the newversion of the configuration knowledge instance.

BRIEF DESCRIPTION OF THE DRAWINGS

Various objects and advantages and a more complete understanding of thepresent invention are apparent and more readily appreciated by referenceto the following Detailed Description and to the appended claims whentaken in conjunction with the accompanying Drawings wherein:

FIG. 1 illustrates one organization of a configuration knowledgeinstance for a network device;

FIG. 2 is a block diagram of one embodiment of the present invention;

FIG. 3 illustrates versioned KDMs and configuration instructions;

FIG. 4 is a block diagram of a network including network managementapplications and configuration knowledge and data storage devices;

FIG. 5 is a flowchart of one method for implementing a roll-back; and

FIG. 6 is a flowchart of one method for implementing a business policyin a network.

DETAILED DESCRIPTION

Individual network devices are typically associated with a deviceconfiguration that controls the operation of that network device. In oneembodiment of the present invention, the device configuration fornetwork device is separated into two portions: configuration knowledgeand configuration data. Configuration knowledge abstractly representsthe capabilities—both logical and physical—of a network device, and theconfiguration data includes information about the actual configurationof the network device. Put simply, configuration knowledge describes thefeatures of a network device, and the configuration data indicates whichfeatures are being used and how they are being used.

Typical configuration knowledge can include separate abstractions foreach feature of the network device. For example, the configurationknowledge for a particular router could list the physical properties ofthe router such as processor type and available cards. Similarly, theconfiguration knowledge could list the logical capabilities of therouter such as available protocols, security features and services. Theactual configuration information for these physical and logicalproperties would be stored with the configuration data instance for thatrouter. Note that the configuration of most network resources, includingrouters, router components, switches, switch components, fabrics,optical devices, and optical components can be divided intoconfiguration knowledge and configuration data.

Referring now to FIG. 1, it illustrates one possible organization 10 ofconfiguration knowledge. This abstraction includes a device family layer12 for devices that all share common features and/or othercharacteristics. A typical device family could be “router” or “CISCOrouter.” The device family layer 12 is refined by the device layer 14,which represents a software abstraction of a specific device. A typicaldevice for the “router” family could be “CISCO,” and a device for the“CISCO router” family could be a particular model of CISCO router. Thedevice family layer 12 can then further refined into its physical andlogical aspects, which are represented by the physical and logicalabstraction layers 16 and 18.

The physical and logical layers 16 and 18 can be refined according tothe features of the family of devices being represented. For example,the logical abstraction for a router can include: address management,services, security, protocols, and traffic conditioning. Similarly, thephysical abstraction can include: cabling, processors, cards, andchassis. These refinements are not inclusive, but rather exemplary forone type of device. Note that the logical and physical layers representthe capabilities of the class of network devices and not the actualconfiguration of any particular device.

By defining the device according to its physical and logicalcapabilities, configuration knowledge can support applications thatrequire access to only physical or logical information. For example,configuration knowledge can be used to support a physical inventoryapplication that has no need of logical information. Likewise, theconfiguration knowledge can support a capacity planning application thathas need for both physical and logical information. In either case, theapplication seeking information need only query the configurationknowledge and not the actual configuration as stored in theconfiguration data.

Configuration knowledge can be organized using object classes,directories, and inheritance properties. For example, the template for anew instance of configuration knowledge for a CISCO router could beformed by creating an instance that inherits the properties of a “CISCOrouter” class, which inherits the properties of the generic “router”class. The template would then be populated with the specificinformation, such as available cards and operating systems, pertainingto the particular CISCO router being modeled.

Once created, individual instances of configuration knowledge can bestored together in a central storage device or distributed acrossmultiple storage devices. For example, the configuration knowledgeinstances for each router on a network could be stored together in acentral facility. The configuration knowledge instances can be stored ina variety of formats, including XML.

Referring now to FIG. 2, it is a block diagram of one embodiment of thepresent invention. In this embodiment, instances of configurationknowledge and configuration data are stored in a configuration storagedevice 20. The configuration storage device 20 is represented as asingle device for simplicity only. It could be arranged in any fashion,including distributed, centralized, or some combination thereof.Additionally, a particular configuration knowledge instance andconfiguration data instance could also be stored at the network device24 to which they correspond.

The configuration storage device 20 is connected to a managementapplication 22 that can be implemented in software or hardware.Additionally, the management application 22 can consist of severalindividual applications, including applications distributed over anetwork. The management application can be responsible for severalfunctions, including:

Facilitation of Search and Accounting of Assets

The management application 22 can search the individual configurationknowledge instances for particular capabilities. For example, themanagement application 22 can search for device capabilities such ashardware and software features of a network device that are no longerbeing used and are otherwise available. For example, consider thecreation of a VPN. This requires dedicating either an interface or asub-interface of a Physical Port of a network device to host the VPNtraffic, along with dedicating logical resources that correspond tocreating the instance of the VPN. This enables the network device toforward traffic on the VPN if the traffic is intended for that VPN. Oneexample of a search is to identify components of a VPN. Similarly, ifthe VPN is subsequently removed, then it is important to reclaim theseallocated resources. Thus, a second example of a search is to ensurethat the components have been removed. A third example of a search is toensure that adequate resources for creating the VPN exist before thecommands are issued to the device. The management application 22 couldalso search the configuration knowledge instances for stranded servicessuch as a virtual private network (VPN) that is no longer being used.Similarly, the management application 22 could search for softwarecapabilities, physical ports, physical assets, and physical containers.In effect, the management application 22 can provide an accurateinventory of the capabilities of a network. Such information can be usedfor network management, provisioning, and identification of strandedassets.

Support for Versioning of Asset Information

The management application 22 can also support versioning of bothconfiguration knowledge and configuration data. For example, multipleversions of configuration data could be associated with a singleinstance of configuration knowledge. Such versioning is particularlyuseful for creating different instances of configuration data that canbe associated with different customer demands. Versioning is describedin more detail with relation to FIG. 3.

Support for Concurrent Editing of Asset Information

The management application 22 can also enable different users to work ondifferent parts of the configuration knowledge and configuration datasimultaneously.

Support for Incremental Update to Versioned Asset Information

The management application 22 can also track which individual featuresof a network device are changed and how those changes impact theconfiguration data. For example, if an updated card was added to aparticular router, then the management application could change only theportion of the configuration knowledge corresponding to the updatedcard. Similarly, only the portion of the configuration instructionscorresponding to the changed portion of the configuration knowledge needbe changed.

Referring now to FIG. 3, it illustrates a versioned configurationknowledge instance and corresponding versions of configuration data. Inthis embodiment, the configuration knowledge instance is associated witha particular network device and includes versions 1 through 4. Theconfiguration data also corresponds to the network device and includesversions 1.1 through 4.3. Each version of the configuration datainstance is associated with at least one of the versions of theconfiguration knowledge. For example, configuration data V1.1 and V1.2correspond to configuration knowledge instance V1. Similarly,configuration data instance V2.1 corresponds to configuration knowledgeinstance V2.

Referring now to FIG. 4, it is a block diagram of a system that includesnetwork management applications 40 connected to a centralizedconfiguration knowledge storage device 42 and configuration data storagedevice 44. In this embodiment, a plurality of network managementapplications 40 are connected to the storage device through a network46. The storage devices 42 and 44 are also connected to network devices48(a) and (b) such as router through the network.

When a network management application 40 needs configuration data abouta particular network device or group of network devices, the networkmanagement application 40 can access the network device 48 directly andread the relevant information. This process, however, generally requiresthe network management applications 40 to understand the particularsyntax of the network device's configuration. In one embodiment of thepresent invention, however, the network management application 40 canaccess the storage device 42 or 44 and retrieve the relevantconfiguration knowledge instances or portions thereof.

Because the configuration knowledge instances are abstractions of thecapabilities of the device, the network management applications 40generally are not required to understand the device-specific syntax of aparticular network device. For example, a physical inventory applicationcould access the configuration knowledge instances for the relevantnetwork devices and determine the cards that are used by each devicewithout regard to the syntax of the actual configuration instructions.

Referring now to FIG. 5, it is a flowchart of one method forimplementing a roll-back using configuration knowledge instances andversioned configuration data. Roll-backs are often useful for networkadministrators after network attacks or after unsuccessful networkdevice updates—although they are useful in several other cases. Forexample, new hardware is often added to existing routers in a network.This new hardware can introduce new capabilities to the router that arereflected in a new version of the router's configuration knowledgeinstance. Additionally, the configuration data for the router is usuallymodified to engage the new hardware. Thus, in this type of systemupgrade, both the configuration knowledge instance and the configurationdata instance for the router are modified.

Assuming that a system upgrade is unsuccessful for some reason, networkadministrators often wish to roll-back the configuration to a previous,known configuration. For example, if the added card was defective, thenetwork administrator might want to remove the defective card androll-back the configuration to a configuration based on router that doesnot include the card. To roll-back the configuration, the assembler orsome other device can identify the device [step 50] and a version of theconfiguration knowledge instance that does not reflect the card'spresence [step 52]. The configuration data associated with that versionof the configuration knowledge instance can then be identified [step 54]and pushed to the network device [step 56].

Referring now to FIG. 6, it is a flowchart of one method for generatinga business object model (BOM) for implementing a specific purpose in anetwork. In this embodiment, a user or application requests a deviceconfiguration to perform a certain function [step 60]. For example,assume that it is desired to create a VPN. The actual list of commandsrequired to accomplish this task vary by vendor and also by version ofthe operating system that the network device is running. Therefore, inorder to provide a single high-level ability to create a VPN, detailedknowledge of the differences in command syntax and semantics must beprovided. In various embodiments of this invention, this is done throughthe use of a BOM, which correlates and assembles the individualknowledge instances. In a preferred embodiment of this invention, therewill be many such BOMs, with a BOM for each type of function. Note thatthe function can be small or large, a command change or a VPN creationbeing examples of each. For the VPN creation, there will be a set ofBOMs that are aggregated into a higher-level BOM. This request ishandled by a BOM assembler. The BOM assembler determines which networkresources are required to carry out the request [step 62]. The BOMassembler next gathers information from the configuration knowledgeinstances associated with the identified network resources [step 66].

Finally, the BOM derives the device configuration from the gatheredconfiguration knowledge instances and generates the actual configurationcommands [step 70]. For example, in the configuration of a VPN, the BOMassembler will select appropriate BOMs, aggregate them together, and usethe aggregated BOM to derive the appropriate device configurationcommands for each device. This enables the device to be programmed at ahigh functional level, and to have these high-level functions translatedto a low-level device-specific implementation. Examples of systems forgenerating commands are described in commonly owned and assigned U.S.patent application Ser. Nos. 09/730,671, entitled “Dynamic Configurationof Network Devices to Enable Data Transfers,” and 09/730,864, entitled“System and Method for Configuration, Management, and Monitoring ofNetwork Resources,” both of which are incorporated herein by reference.In one embodiment, the device configuration is derived by binding thevariable information within the configuration knowledge instances to thebusiness purpose of the customer. For example, a QoS business purposecould be bound to the various traffic conditioning settings.

In conclusion, the present invention provides, among other things, asystem and method for managing and utilizing network deviceconfigurations. Those skilled in the art can readily recognize thatnumerous variations and substitutions may be made in the invention, itsuse and its configuration to achieve substantially the same results asachieved by the embodiments described herein. Accordingly, there is nointention to limit the invention to the disclosed exemplary forms. Manyvariations, modifications and alternative constructions fall within thescope and spirit of the disclosed invention as expressed in the claims.

1. A network data construct for use in a network device managementsystem, the network data construct comprising: a plurality ofconfiguration knowledge instances, and a plurality of configuration datainstances.
 2. The network data construct of claim 2, wherein eachconfiguration knowledge instance comprises at least one configurationknowledge schemata.
 3. The network data construct of claim 2, whereineach configuration knowledge instance comprises a plurality of layersselected from a group consisting of a device family layer, a devicelayer, a physical layer, and a logical layer.
 4. The network dataconstruct of claim 2, wherein the configuration knowledge instances areorganized using object classes.
 5. The network data construct of claim2, wherein the configuration knowledge instances are organized usingdirectories.
 6. The network data construct of claim 2, wherein theconfiguration knowledge instances are organized using inheritanceproperties.